home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11782 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 15 Mar 1996 20:21:27 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4idfk7INNngh@keats.ugrad.cs.ubc.ca>
  8. References: <00001a73+00002504@msn.com> <4icja9$1r92@saba.info.ucla.edu> <4ictacINN5gk@mayne.ugrad.cs.ubc.ca> <4idagc$ldi@saba.info.ucla.edu>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4idagc$ldi@saba.info.ucla.edu>,
  12. Jay Martin <jmartin@cs.ucla.edu> wrote:
  13. >c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
  14. >
  15. >>>Its stupid to bring in two tools with two more
  16. >>>"languages" to do something trivial that takes a page of normal code.
  17. >
  18. >>Your last sentence is an example of obsolete thinking....
  19. >
  20. >Every tool, language, library, etc, that you use on a project
  21. >increases its complexity and maintanance costs.  The people who have
  22. >to maintain or reuse the code must know all the tools and all the
  23. >languages and tools must talk together correctly.  Suppose you want to
  24. >do sorting, COBOL is the best for that or logic: PROLOG, calculations:
  25. >FORTRAN, pretty soon you will have problems getting all the pieces
  26. >talking together and anyone to work on it.  Thus, the savings gained
  27. >by the tool must offset the pain of using the tool.  Forcing expertise
  28. >in yacc parsing for a page of code is not worth it, IMHO.
  29. >
  30. >In a recent case using a yacc parser structure made the code harder to
  31. >use when converting to a GUI interface or trying to reuse parts of it.
  32.  
  33. Are you sure that the yacc was at fault here? How would it have helped the
  34. conversion had a hand-coded parser been used? This sound like a moot case.
  35.  
  36. Why couldn't you keep the parser and add a GUI?
  37.  
  38. Clearly, not all uses of yacc represent good design. Some people write yacc
  39. files with actions that are simply huge, instead of moving the code to
  40. well defined modules. You may have suffered from the case of the monolithic
  41. yacc spec.
  42.  
  43. Poor yacc practice can lead to many mistakes. For example, sometimes the
  44. grammar will require you to write two similar productions to do almost the same
  45. thing. For example, a production like:
  46.  
  47. foo -> a b ( c | d ) e  { action }
  48.  
  49. meaning that c or d can occupy the place, has to be split into two. And so does
  50. the action, of course. If the action is more than just two or three lines that
  51. call an external function (such as something that builds a node), you have to
  52. repeat all the code for both expansions of foo, and thereafter maintain two
  53. separate copies in parallel. Messy!
  54.  
  55. Anyway, I'm sure that some other newsgroups are much more appropriate to
  56. yacking about this sort of stuff.
  57. -- 
  58.  
  59.